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Executive  Summary 

Current  Department  of  Defense  (DoD)  strategy  highlights  the  need  for  information 
sharing  and  system  interoperability  as  an  essential  requirement  to  support  the  needs  of  near-term 
and  future  war-fighting  capabilities.  Weapons  systems  fielded  by  the  U.S.  Air  Force  are 
conceptualized  and  delivered  by  the  Air  Force  product  centers.  This  report  examines  the  Air 
Force  product  centers  and  provides  a  roadmap  for  future  integration  success.  In  July  2010,  Air 
Force  Institute  of  Technology  (AFIT)  Associate  Professor,  Alan  R.  Heminger,  Ph.D.  engaged 
graduate  students  at  AFIT  to  explore  these  issues  with  a  focus  on  Early  Systems  Engineering 
(ESE)  initiatives  led  by  the  Center  for  Systems  Engineering  (CSE).  These  initiatives  fall  under 
an  umbrella  which  the  CSE  has  labeled  collaborative  early  systems  engineering  (CESE).  The 
AFIT  research  team  generated  this  report  to  provide  the  CSE  with  refined,  actionable,  way-ahead 
recommendations  for  developing  and  implementing  CESE  across  the  Air  Force  product  centers. 
The  findings  and  recommendations  produced  from  this  study  are  listed  below. 

Findings: 

1 .  The  Air  Force  Product  Centers  appear  to  be  operating  in  Weill’s  diversification  operating 
model.  Characteristics  of  this  model  include  low  business  process  standardization  and  low 
business  process  integration.  There  are  a  number  of  characteristics  that  the  product  centers 
display  that  support  this  conclusion.  Among  those  characteristics  we  found  the  following: 

a.  Each  center  has  a  unique  culture 

a.  Each  center  has  a  specific  mission  with  distinct  functional  requirements 

b.  Each  center  works  with  different  contractors  and  customers 

c.  Each  center  uses  different  business  processes,  standards,  and  technology 

d.  Each  center  is  geographically  separated  from  the  others 

e.  Each  center  has  a  different  organizational  structure 

2.  From  the  standpoint  of  enterprise  architecture  (EA)  the  product  centers  are  in  the  business 
silo  stage.  At  this  stage,  each  center’s  information  stores  and  tools  serves  its  own  local  needs. 
Sharing  across  centers  is  not  a  realistic  option  at  this  stage. 

3.  CSE  initiated  participation  in  the  Development  Planning  working  group;  however,  its 
involvement  is  still  early. 

4.  CSE  has  initiated  working  groups. 


Recommendations: 

1 .  The  product  centers  should  consider  moving  toward  a  Coordination  Operating  Model. 

2.  The  product  centers  should  consider  the  stage  of  their  enterprise  architecture,  with  a  goal  of 
moving  from  stage  1 ,  the  Business  Silo  stage  to  stage  three,  Optimized  Core,  or  stage  four, 
Business  Modularity  to  support  the  need  to  develop  interoperable  weapon  systems. 
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3.  The  Center  for  Systems  Engineering  (CSE)  should  become  the  vehicle  for  coordinating  the 
effort  to  move  the  product  centers  toward  a  coordination  operating  model  and  an  enhanced 
enterprise  architecture  stage. 

4.  CSE  should  consider  working  with  the  product  centers  to  establish  a  plan  with  scheduled 
milestones  for  moving  toward  compliance  with  the  new  DoD  policy/guidance  regarding 
information  sharing  and  interoperability. 

5.  CSE  should  consider  furthering  its  involvement  in  the  Product  Center  working  groups. 
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1.  Introduction/Background 

Problem  Statement 

Current  Department  of  Defense  (DoD)  strategy  highlights  the  need  for  information 
sharing  and  system  interoperability  as  an  essential  capability  of  new  U.S.  weapon  systems. 
Achieving  this  goal  will  enhance  the  ability  of  U.S.  warfighters  to  meet  the  demands  of,  and 
dominate  over,  a  rapidly  changing  threat  environment  that  appears  to  be  the  norm  for  the 
foreseeable  future.  However,  to  make  this  objective  a  reality,  it  will  take  a  unified  effort  by  all 
weapons  system  development  centers,  both  within  each  service  and  across  the  DoD.  The  Air 
Force  Product  Centers  represent  an  area  where  this  focus  is  needed.  The  product  centers  include: 
Aeronautical  Systems  Center  (ASC),  Electronic  Systems  Center  (ESC),  Nuclear  Weapons  Center 
(NWC),  Air  Armament  Center  (AAC),  and  Space  and  Missile  Systems  Center  (SMC).  These 
Centers  are  responsible  for  the  full  lifecycle,  from  creation  to  completion,  of  all  weapons  systems 
developed  for  the  Air  Force.  Their  ability  to  work  together  is  critical  to  providing  the 
information  sharing  and  interoperability  required  by  the  DoD.  This  report  examines  the  Air 
Force  product  centers  from  the  standpoint  of  information  sharing  and  potential  for  developing 
interoperability  and  provides  a  roadmap  for  future  integration  success. 


Purpose 

In  July  2010,  the  Center  for  Systems  Engineering  (CSE)  contacted  Dr.  Alan  Heminger, 
Associate  Professor  at  the  Air  Force  Institute  of  Technology  (AFIT)  to  help  advance  Early 
Systems  Engineering  (ESE)  initiatives  led  by  the  Center  for  Systems  Engineering  (CSE).  Dr. 
Heminger  supervised  a  team  of  graduate  students  at  AFIT  to  undertake  this  task.  This  initiative 
falls  under  an  umbrella  which  the  CSE  has  labeled  collaborative  early  systems  engineering 
(CESE).  Over  the  past  year,  AFIT  teams  have  investigated  current  CESE  processes,  tools, 
cultural  issues,  and  knowledge  management  capabilities  across  the  Air  Force  Product  Centers. 
The  current  AFIT  research  team  generated  this  report  to  provide  the  CSE  with  recommendations 
for  developing  and  implementing  CESE  across  the  Air  Force  Product  Centers. 


The  Team 

This  research  team  worked  under  the  direction  and  guidance  of  Dr.  Alan  Heminger, 
(AFIT  faculty)  and  Lt  Col  William  O’Connor  (CSE).  The  team  members  consist  of  United 
States  Air  Force  (USAF)  and  United  States  Army  (USA)  personnel  from  diverse  functional 
backgrounds.  The  members  are: 


CPT  Jason  Bray,  USA 
CPT  Michael  Killaly,  USA 
Capt  Woo-Suk  Chun,  USAF 
Capt  Tim  Gannon,  USAF 
Capt  Travis  Johnson,  USAF 
Capt  Dale  Mull,  USAF 
Capt  Jonathan  Needham,  USAF 
Capt  Mark  Richey,  USAF 


Capt  Krishna  Surajbally,  USAF 
Capt  Hans  Winkler,  USAF 
Capt  Stephen  Woskov,  USAF 
lLt  David  Ho,  USAF 
MSgt  Carissa  Parker,  USAF 
MSgt  Christy  Peterson,  USAF 
MSgt  Jason  Royals,  USAF 
TSgt  Joseph  Hicks,  USAF 


Center  for  Systems  Engineering  (CSE) 

In  early  2002,  Air  Force  Materiel  Command  (AFMC)  identified  gaps  and  shortfalls  in  the 
implementation  of  systems  engineering  (SE)  throughout  the  Air  Force  acquisition  process. 
Subsequently,  AFMC  made  recommendations  to  improve  and  institutionalize  SE  concepts 
throughout  the  Air  Force  and  DoD  acquisition  processes.  The  Secretary  of  the  Air  Force  then 
provided  oral  direction  in  April  2002  for  AFMC/CC  (Air  Force  Materiel  Commander)  and 
AFIT/CC  (Air  Force  Institute  of  Technology  Commander)  to  establish  the  CSE,  which  would 
implement  these  recommendations. 

In  December  2003,  AFMC/CC,  AFSPC/CC  (Air  Force  Space  Command  Commander), 
and  AETC/CC  (Air  Education  and  Training  Commander)  signed  a  Memorandum  of  Agreement 
(MOA)  establishing  CSE  as  the  Air  Force  SE  focal  point.  This  MOA  defined  the  CSE’s  roles  as: 
advocating  for  SE  by  documenting  case  studies,  developing  standards  and  tools,  generating  core 
guidance  and  policy  recommendations;  supporting  collaboration  across  the  Air  Force  and  other 
services  by  capturing  and  making  available  current  SE  knowledge  residing  within  each 
organization;  providing  consulting  services  on  SE  issues  by  assisting  organizations  in  obtaining 
SE  expertise;  and  providing/supporting  SE  education  and  training  by  leveraging  resources  from 
academia,  industry,  and  professional  organizations  in  order  to  tailor  applications  for  Air  Force 
needs. 

Although  CSE  is  embedded  within  AETC’s  chain-of-command,  the  MOA  enables 
support  from  HQ  (Head  Quarters)  AFMC/EN  (Directorate  of  Engineering)  as  required.  As  such, 
CSE  leverages  HQ  AFMC/EN ’s  functional  chain  in  order  to  establish  a  command-wide  presence 
to  accomplish  their  mission.  HQ  AFMC/EN  oversees  SE  discipline  at  four  of  the  five  Air  Force 
Product  Centers:  Aeronautical  Systems  Center  (ASC),  Electronic  Systems  Center  (ESC),  Nuclear 
Weapons  Center  (NWC),  and  Air  Armament  Center  (AAC).  Space  and  Missile  Systems  Center 
(SMC)  is  the  fifth  Product  Center,  organized  under  HQ  AFSPC/A4A6  (Director  of  Logistics  and 
Communications).  HQ  AFSPC/A4A6  is  also  MOA  signatory,  providing  support  to  CSE  as 
required.  Outside  of  support  available  through  HQ  AFMC  and  HQ  AFSPC,  CSE  may  champion 
their  efforts  with  assistance  from  the  Assistant  Secretary  of  the  Air  Force  Directors  for 
Acquisition  Integration  (SAF/AQX)  and  Science,  Technology,  and  Engineering  (SAF/AQR). 


Collaborative  Early  Systems  Engineering 

As  CSE  explored  ways  to  advance  the  SE  discipline  across  the  Air  Force,  its 
investigation  converged  on  improving  materiel  acquisition  during  early  systems  engineering 
(ESE)  as  a  primary  goal.  ESE  is  the  application  of  SE  processes  and  products  during  early  (pre- 
Milestone  A)  stages  of  the  DoD  acquisition  process.  This  phase  of  materiel  acquisition  is  known 
as  Concept  Exploration  and  Refinement,  and  is  typically  led  by  subject  matter  experts  (SMEs) 
residing  in  each  acquiring  command’s  Capabilities  Integration  Directorate  (XR)  offices.  For 
ESE  guidance,  SMEs  may  refer  to  the  initial  release  of  the  Early  Systems  Engineering  Guide 
(2009),  which  focuses  on  SE  efforts  necessary  to  produce  the  analysis  of  alternatives  for  a  given 
capability  requirement.  Accordingly,  each  ESE  process/product  contributes  to  the  eventual 
delivery  of  a  system  possessing  capabilities  that  meet  or  exceed  JCIDS  (Joint  Capabilities 


Integration  and  Development  System)  requirements,  whether  the  system  is  approved  either  as  a 
new  program  start  or  legacy  system  modi  lication/upgrade. 

ESE  processes/products  include,  but  are  not  limited  to:  mission  task  decomposition, 
concept  engineering,  concepts  of  operations,  Operational  View  1  (OV-1),  concept 
characterization  and  technical  description  (CCTD),  capstone  requirements  documents,  technical 
trade-space  documentation,  initial  capabilities  documents,  developing  initial  requirements 
baselines,  and  work-breakdown  structures.  A  centralized  clearinghouse  of  data  is  vital  to 
effective  ESE  execution.  As  such,  the  ESE  Guide  recommends  that  concept  engineering  teams 
create  a  repository  and  populate  it  with  concept  templates,  background,  specific  definitions, 
analyses,  evaluations,  reports,  educational  materials,  compliance  documentation,  security 
compliance  criteria,  etc.  The  repository  should  also  be  used  to  catalog  concept  engineering  tools, 
while  providing  interfaces  to  outside  organizations  or  specialized  bodies  of  knowledge. 

The  ESE  discipline  holds  significant  potential  to  coordinate  the  SE  components  of  early 
materiel  acquisition,  which  boosts  efficiencies  necessary  to  rapidly  field  warfighter  capabilities. 
While  ESE  will  enable  front-end  reductions  in  materiel  life-cycle  costs,  the  game-changing  value 
of  ESE  is  rooted  in  the  coordinated  development  of  materiel  solutions  that  meet  requirements 
and  interoperate  to  achieve  synergistic  effects.  Hence,  CSE  is  promoting  collaboration  among 
the  Air  Force  product  centers  as  a  means  of  improving  ESE,  referred  to  as  collaborative  early 
systems  engineering  (CESE).  CSE  aims  to  drive  CESE  by  working  with  the  product  centers  to 
define  new  standards,  tools,  processes,  guidance,  and  policy.  CESE  will  immerse  the  Air  Force 
product  centers  in  a  coordinated  working  environment,  increasing  the  overall  effectiveness  of 
materiel  solutions  to  warfighter  requirements.  Additionally,  CESE  will  enhance  inter-service 
materiel  acquisition  by  promoting  an  open  architecture  for  integrating  SE  practices  among  joint 
programs. 

Development  Planning 

Sound  decisions  regarding  capabilities-based  requirements  are  critical  to  materiel 
acquisition  success  in  today’s  environment  of  declining  budgets  and  rapidly  evolving  threats. 
With  that,  decisions  made  prior  to  program  initiation  have  tremendous  impact  on  subsequent 
development  and  production  costs,  and  opportunities  to  influence  these  factors  rapidly 
diminishes  as  the  acquisition  process  progresses.  Many  decisions  are  made  with 
insufficient  technical  analysis  and  planning  to  sufficiently  identify,  assess,  and  inform  senior  Air 
Force  leaders  of  the  technical  risks  associated  with  acquiring  a  given  materiel  solution.  The 
absence  of  early  technical  information  may  result  in  solution  strategies  that  have  not  surveyed  a 
sufficient  spectrum  of  technical  and  joint  mission  area  opportunities.  Hence,  programs  may  be 
initiated  with  poorly  conceived  requirements,  inaccurate  cost  and  schedule  estimates,  unknown 
and  costly  technical  risks,  deficient  engineering/analysis  to  mitigate  program  risks,  and  lost 
opportunities  to  integrate  solutions  across  the  spectrum  of  weapon  systems.  Such  decisions  are 
unacceptable,  and  the  Air  Force  is  committed  to  recapturing  acquisition  excellence. 

The  Weapon  Systems  Acquisition  Reform  Act  of  2009  (WSARA)  requires  DoD  to 
develop  policies  and  guidance  for  the  acquisition  workforce  responsible  for  SE  and  Development 
Planning  (DP).  Therefore,  WSARA  provides  the  impetus  for  re  invigorating  DP  among  the 
services.  In  short,  the  objective  of  DP  is  to  ensure  high  confidence  programs  that  deliver  weapon 
systems  with  appropriate  capabilities,  on  time,  and  on  cost.  DP  is  not  a  separate 
phase  of  acquisition,  but  rather  a  suite  of  best  practices  and  processes  to  ensure  successful  early 
acquisition  planning.  DP  provides  integrated  assessments  of  performance,  cost,  and  risk  to 
enable  competent  investment  decisions  regarding  concepts  (prospective  materiel  solutions)  to 


meet  identified  operational  capability  requirements.  Rigorous  SE  processes  are  key  to  the 
success  of  this  endeavor. 

In  fact,  DP  emphasizes  pre-Milestone  A  application  of  ESE’s  best  practices  in  order  to 
meet  materiel  requirements.  As  such,  DP  is  designed  to  promptly  execute  ESE  processes  that 
accurately  define  the  relevant  technical  elements  of  each  concept.  However,  DP’s  efficacy 
hinges  on  concept  characterizations  and  technical  descriptions  (CCTD)  as  enduring  products  of 
ESE,  which  capture  the  analytical  basis  of  the  concepts  (prospective  materiel  solutions)  and 
associated  technologies  necessary  to  address  materiel  requirements. 

In  2010,  AFMC/CV  (Air  Force  Materiel  Command  Vice  Commander)  and  APSPC/CV 
(Air  Force  Space  Command  Vice  Commander)  signed  a  DP  Governance  Charter  which 
established  the  organizational  structure,  purpose,  and  operating  procedures  for  Working  Group, 
Board,  and  Council  forums.  This  Governance  Structure  evaluates,  integrates  and  manages  Air 
Force  materiel  DP  efforts.  The  DP  Working  Group  serves  as  an  advisory  and  execution  body  to 
the  DP  Board  and  Council  to  ensure  optimum  materiel  options  in  response  to  Air  Force  shortfalls 
and  gaps. 

Reports 

Recent  investigations  by  AFMC  and  AFIT  have  identified  areas  in  the  DoD  acquisition 
process  requiring  more  CESE  among  the  stakeholders.  In  2010,  an  AFIT  team  investigated  the 
need  for  CESE  at  the  Air  Force  product  centers.  The  report  identified  current  implementations 
of  CESE  within  centers,  but  also  identified  a  lack  of  collaboration  among  the  centers  themselves. 
Common  tools,  nomenclature,  understandings,  and  processes  to  support  CESE  are  not  present 
due  to  this  lack  of  communication.  Recently,  a  team  of  AFIT  researchers  looked  at  knowledge 
management  (KM)  within  and  among  the  Air  Force  product  centers  with  the  2010  report  in 
mind.  The  team  recommended  KM  assessments,  identifying  various  knowledge  types  in  the 
organizations,  and  implementing  a  knowledge  repository  system. 


Strategic  Information  Management  Lens 

The  approach  toward  improving  CESE  can  be  viewed  from  a  number  of  different 
perspectives.  In  this  report,  the  team  analyzed  the  problem  from  a  Strategic  Infonnation 
Management  (SIM)  perspective.  SIM  is  based  on  the  concept  that  good  strategic  infonnation 
underlies  good  strategic  decisions,  and  that  having  good  strategic  information  does  not  simply 
happen.  It  must  be  planned  for,  gathered,  interpreted,  organized,  integrated,  stored,  updated,  and 
made  available  for  dissemination  as  needed  for  strategic  decisions.  For  all  of  this  to  happen, 
there  must  be  a  conscious  focus  on  organizational  goals,  customer  needs,  and  common 
understanding  across  the  enterprise.  There  must  be  knowledge  of  what  strategic  decisions  are  to 
be  made  and  what  information  is  necessary  to  support  those  decisions. 

Galliers  (2009)  conceptualized  SIM  in  four  concentric  rings  as  shown  in  Figure  1 . 
Information  systems  (IS)  strategy,  the  core  of  SIM,  is  comprised  of  four  interrelated  strategies: 
information,  information  management,  information  technology  and  change  management 
strategies.  Technology  becomes  more  powerful  with  each  passing  day  and  is  increasingly 
available  at  a  low  to  modest  cost.  Some  would  argue  that  technology  no  longer  provides  a 
distinguishing  competitive  edge.  Instead,  the  strategy  to  utilize  that  technology  provides  the 
competitive  edge  distinction.  The  focus  should  be  on  people ’s  creative  use  of  the  technology 
systems  rather  than  the  technology  itself  (Dearstyne,  2002). 


Figure  1.  Conceptualization  of  SIM 

SIM  continues  to  be  a  critical  issue  in  the  twenty-first  century,  as  society  grows  reliant  on 
information  and  communication  technology.  Sound  SIM  provides  organizations  with 
“...flexibility,  responsiveness  to  change  and  ability  to  respond  to  new  challenges  (Dearstyne, 
2004).”  Organization  success  becomes  dependent  on  an  organization’s  ability  to  effectively  and 
efficiently  utilize  IT  within  the  firm  (Galliers  &  Leidner  2009). 


2.  The  Air  Force  Product  Centers 

Current  Strategic  Information  Management  in  Product  Centers 

A  key  focus  for  CSE  is  the  smart  design  of  processes  that  guide  acquisition  business 
practices  and  product  development.  Currently,  the  product  centers  operate  with  unique  and 
mostly  uncoordinated  efforts.  In  review  of  “An  Investigation  of  Air  Force  Product  Center  Needs 
for  Supporting  of  Collaborative  Early  Systems  Engineering,”  the  recent  efforts  of  CESE  are 
important  to  discuss  in  the  context  of  SIM. 

Product  centers  are  continually  in  the  process  of  optimizing  for  their  own  business 
priorities,  which  creates  friction  points  when  endeavors  for  holistic  systems  engineering  attempt 
integration.  Perhaps  a  major  reason  why  this  occurs  is  because  of  the  unique  cultures  of  the 
centers.  Unique  cultures  result  from  the  different  products,  quantities,  costs  per  product,  cycle 
times,  manufacturing  tolerances,  number  of  customers,  interface  requirements,  and  overall 
tolerance  for  risk  for  each  product  center.  Table  1  below  shows  a  general  comparison  of  two 
product  centers  as  reviewed  by  Mr.  Richard  Freeman  (Technical  Director,  CSE).  Air 
Armaments  Command  (AAC)  and  Space  and  Missile  Command  (SMC)  are  two  of  the  most 
dissimilar  product  centers  and  provide  a  good  example  of  the  unique  challenges  faced  by  each. 
The  table  reveals  a  large  relative  difference  in  a  number  of  categories.  The  nature  of  the  work 
and  associated  cultural  environment  is  noteworthy. 


AAC 

SMC 

Products 

Weapons 

Space  Vehicles 

Quantity 

Many 

Each 

Cost  per  Product 

i  (<$1M) 

t (>$  IB) 

Cycle  Time 

Short  (1-3  yrs) 

Long  (5-20  yrs) 

Manufacturing  Tolerance 

I 

|  (Higher  sensitivity) 

Number  of  Customers 

Many 

Few 

Interface  Requirements 

Many 

Few 

Tolerance  for  Risk 

t 

Table  1.  Product  Center  Relative  Comparison:  AAC  &  SMC  (Freeman  2010) 

A  consideration  of  the  differences  identified  in  Table  1  between  AAC  and  SMC  suggests 
some  of  the  reasons  why  they  have  developed  different  approaches  and  cultures.  AAC  develops 
weapons  that  are  often  purchased  in  large  lots  over  time,  and  that  are  relatively  inexpensive, 
compared  to  SMC’s  efforts.  SMC,  on  the  other  hand,  undertakes  relatively  few  space  shots  that 
may  be  in  development  for  decades,  and  are  more  expensive  by  orders  of  magnitude.  As  a  result, 
SMC  is  likely  to  be  much  more  risk  averse  than  AAC.  With  a  higher  risk  aversion,  SMC 
routinely  engages  in  more  conservative  practices  with  redundant  desk  drills  and  formal 
checklists.  On  the  other  hand,  AAC’s  lack  of  dependence  on  a  single  launch  of  a  missile  that 
costs  billions  of  dollars,  leads  to  a  culture  that  is  not  as  highly  risk  averse,  leading  to  more 
tolerance  for  cross  center  interchanges  and  more  dynamic  standard  enforcement  practices 
(Freeman  2010).  Some  of  the  product  centers  may  have  more  in  common  than  AAC  and  SMC. 
Regardless,  different  cultures  are  present.  All  of  the  nuances  and  unique  pressures  of  each 
product  center  encourages  divergence.  This  cultural  friction  appears  to  be  a  major  source  of 
resistance  to  collaboration  and  sharing  information. 

Even  so,  the  product  centers  have  the  opportunity  to  make  a  significant  contribution  to 
better  infonnation  management.  By  employing  the  philosophy  and  services  of  CESE  along  with 
new  IT  capabilities  in  a  more  strategic  format,  a  migration  in  SIM  architecture  is  possible. 

Thf  Role  of  Development  Planning  Working  Group 

Recently,  attempts  of  progressing  CESE  have  been  made  through  the  Development  Planning 
Working  Group  (DPWG).  According  to  the  USAF  Material  Commands’  Development  Planning 
Governance  Charter  dated  26  Jan  2010,  the  mission  of  the  DPWG  is  to  “recommend 
prioritization  of  Air  Force  DP  efforts  to  the  DP  Board  and  conduct  quarterly  vetting,  integrating, 
and  statusing  of  the  DP  activities  that  are  executed  by  AFMC  and  AFSPC  Material  Centers.” 
Additionally,  the  responsibilities  of  the  DPWG  involve: 

•  Providing  centralized  integration  of  Material  Center  DP  support 

•  Assisting  in  the  identification  and  assessment  of  horizontal  integration  or  cross¬ 
cutting  opportunities 

•  Identifying  and  recommending  the  use  of  standard,  consistent  tools 


The  activity  and  efforts  of  the  DPWG  over  the  past  year  (Oct  09  to  present)  was  reviewed 
from  documents  available  through  the  AFMC/AFSPC  Development  Planning  CoP  (Community 
of  Practice)  on  AFKN  (Air  Force  Knowledge  Now).  Activity  found  to  be  relevant  to  integration 
and  collaboration  included: 

•  Oct  2009  DP  Strategic  Workshop: 

1 .  Attendees  discussed  and  agreed  upon  the  definitions  of  common  DP  terms 

2.  “Collaborative  Development  Centers”  was  mentioned  as  a  “Future  Path 
Ahead”  in  the  SAF/AQR  Vision  of  DP  briefing 

•  Apr20100-6W  orking  Group : 

1.  A  Cross-Center  Integration  briefing  was  conducted  by  Ms.  Terri  Dorpinghaus, 
HQ  AFSPC/A5X.  The  briefing  identified  “Integration  Teammates,” 
representing  each  of  the  5  AF  Product  Centers  and  HQ  AFMC/A5C;  it 
discussed  the  purpose  of  the  integration  effort,  what  work  the  team  had  already 
accomplished,  and  future  integration  topics;  and  how  leadership  would  be 
involved  (namely  the  0-6  WG). 

•  Aug  2010  DPWG: 

1 .  A  Proposal  for  a  CESE  Environment  briefing  was  presented  by  Col  John 
Paschall,  Acting  CSE  Director.  This  briefing  provided  the  problem  statement, 
phased  CESE  development,  and  the  proposed  way  ahead. 

The  CSE-AFIT  team,  which  conducted  an  investigation  of  Air  Force  Product  Center  needs  in 
early  2010,  stated  that  they  believed  DP  to  be  an  ideal  launch  pad  for  CESE.  Though  the 
observations  of  past  DPWG  involvement  in  ESE  integration/collaboration  issues  were  not 
plentiful,  there  is  evidence  that  these  ideas  are  not  new.  The  recent  CESE  proposal  may  serve  as 
a  catalyst  for  bringing  such  issues  to  the  forefront  of  the  DPWG.  Overall,  continuous  and 
consistent  focus  on  CESE  will  be  needed  in  the  DPWG  if  progress  is  expected. 


Early  Systems  Engineering  Concepts 

An  organization’s  reason  for  existence  is  conveyed  through  its  mission  statement.  The 
CSE’s  mission  is  to  “develop  new  SE  concepts  that  will  provide  processes,  practices,  tools  and 
resources  to  the  SE  workforce  through  research,  education,  and  consultation  for  air,  space  and 
cyberspace  competence.”  In  accordance  with  this  mission,  CSE  has  produced  a  guidebook  for 
ESE.  This  guidebook  underscores  concepts  of  how  SE  can  assimilate  acquisition  efforts. 

As  referenced  in  the  ESE  Guidebook,  the  2006  Defense  Acquisition  Performance 
Assessment  (DAP A)  Project  Report  Survey  results  showed  that  requirements  instability  was  the 
most  mentioned  problem  area,  followed  by  funding  instability  and  technology  maturity.  To 
minimize  costly  and  time-consuming  changes  during  development  process,  requirements  must  be 
expressed  with  completeness  and  accuracy.  These  requirements  must  be  assessed  and  balanced 
with  respect  to  parameters  such  as  effectiveness,  cost,  schedule,  risk,  and  evolutionary  potential; 
this  is  a  key  element  of  the  Analysis  of  Alternatives  (AoA)  that  selects  a  Preferred  System 
Concept  (PSC).  SE  collects,  coordinates,  and  ensures  traceability  of  all  stakeholder  needs  into  a 


set  of  system  requirements  through  a  balanced  process  that  takes  into  account  effectiveness, 
performance,  cost,  schedule,  and  risk.  Also  early  SE  provides  an  audit  trail  from  the  users’ 
capability  gaps  and  needs.  Early  SE  can  be  divided  into  four  segments: 


•  Capabilities-Based  Assessment  (CBA) 

•  Concept  Exploration  and  Refinement  (CER) 

•  Preferred  System  Concept  (PSC)  maturation 

•  Technology  Development  (TD) 

CBA  develops  potential  material  and  non-material  concepts  to  address  capability  gaps  and 
shortfalls,  or  to  exploit  new  capabilities  provided  by  new  technologies.  CER  provides  for 
developing  material  solutions  to  warfighter  shortfalls  and  refining  the  activities  at  the  front  end 
of  the  acquisition  life  cycles.  CER  is  intended  to  enhance  the  quality  and  fidelity  of  proposed 
future  military  system  concepts.  Each  concept  developed  under  CER  will  have  been  technically 
researched,  analyzed,  and  evaluated  against  a  validated  set  of  mission-based  requirements  and 
costs  for  the  entire  life  cycle.  The  concept  engineering  team  is  responsible  for  creating  and 
delivering  all  documentation  and  executing  all  control  milestones  and  reviews. 

Post-AoA  phase  is  where  the  PSC  is  matured  into  a  stable,  producible,  testable,  supportable, 
and  affordable  program.  PSC  maturation  efforts  are  characterized  by  the  planning  necessary  to 
ensure  a  high  confidence  of  program  success.  Post-AoA  must  include  all  activities  necessary  to 
successfully  complete  the  TD  phase.  Key  TD  efforts  include: 

•  Exploring  the  feasibility  of  the  operational  requirements  and  maturing  the  initial 
capability  document  into  a  final  capability  document 

•  Mitigating  risks  to  the  level  necessary  to  support  a  favorable  milestone  B  decision 

•  Developing  a  preliminary  design  of  PSC  that  is  feasible,  affordable,  and  will  meet 
operational  requirements 

•  Determining  the  affordability  and  military  utility  of  the  preliminary  design  before 
committing  to  full  system  development 

Risk  management  is  the  heart  of  technical  and  SE  planning  during  Post-AoA  phase  and  a 
critical  first  step  toward  affordable,  manageable,  and  executable  TD  phase  efforts. 


Integration  of  Systems  Engineering  into  the  Product  Centers 

A  major  SE  dilemma  in  addressing  problems  in  a  complicated  system  is  how  to  actually 
integrate  the  concept  of  SE.  Integrating  the  SE  solution  involves  boundary  clarification.  The 
product,  enterprise,  and  service  view  model  of  integration  presented  below  in  Figure  2  shows 
how  current  endeavors  are  intended  to  impact  different  boundaries  at  once  (Freeman,  2010). 


Systems  Engineering 

♦♦♦  Product,  Enterprise  &  Service  View  Model 
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Figure  2.  System  Engineering  Integration  Slide 

Systems  engineering  can  provide  the  integration  of  business  processes  and  systems 
processes,  based  on  support  for  an  enterprise  architecture  that  extends  not  only  across  the 
traditional  SE  focus,  but  across  the  enterprise  as  well.  It  also  provides  a  vehicle  for  integrating 
the  needs  of  the  customer:  at  requirements  gathering,  product  delivery,  and  service  after  delivery. 

Overall,  today’s  poor  status  of  strategic  management  of  information  across  the  product 
centers  validates  the  need  for  SE.  SE  maintains  a  holistic  approach  that  will  only  be  effective  if 
incorporated  into  the  congruent  efforts  of  the  DPWG.  Continued  emphasis  on  utilizing  the 
existing  guidebook  on  ESE  will  also  help  establish  a  foundation  for  future  use.  A  consideration 
of  how  SIM  can  accentuate  the  SE  efforts  from  an  “operating  model”  and  a  “stages  of  enterprise 
architecture”  perspective  is  provided  in  the  following  sections. 


3.  An  Operating  Model  View  of  Support  for  CESE 

One  of  the  roles  for  CSE,  as  designated  in  the  2003  MOA,  is  to  provide  a  means  for 
collaborative  SE  work  efforts  across  the  Air  Force,  among  the  Armed  Services  and  DoD.  A 
2010  report  investigating  the  Air  Force  Product  Center  Needs  for  Support  of  CESE  recommends 
that  the  CSE  become  the  vehicle  for  breaking  down  the  isolation  among  the  centers  and  for 
fostering  collaboration  across  all  aspects  of  systems  engineering  with  a  focus  on  ESE. 

Weill  (2008)  developed  an  organizational  operating  model  based  on  high  and  low  business 
process  standardization  and  integration  (Figure  3).  Low  business  process  standardization  and 
low  business  process  integration  results  in  a  diversification  operating  model,  in  which  each 


organizational  unit  operates  largely  independently.  It  focuses  on  optimizing  each  separate  unit 
independently  of  the  others.  The  operating  units  are  seen  as  having  little  in  common  with  each 
other. 

FOUR  OPERATING  MODELS 
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Business  Process  Standardization 

Figure  3:  Focus  of  Standardization  by  model  {Weill,  2008) 

With  high  business  process  standardization  and  low  business  process  integration,  a 
replication  model  results,  in  which  each  operational  unit  performs  similarly  to  the  other  units. 
Individual  differences  are  minimized.  However  the  work  of  the  various  units  is  not  designed  for 
integration  of  effort. 

With  high  business  process  standardization  and  high  business  process  integration,  a 
unification  model  results,  in  which  the  business  units  operate  similar  to  each  other.  They  share 
data  and  respond  to  common  customers.  This  model  focuses  on  supporting  units  that  operate 
similarly  for  common  customers. 

High  business  process  integration  and  low  business  process  standardization  results  in  a 
coordination  operating  model.  In  this  model,  while  the  business  processes  are  similar  and 
infonnation  is  shared,  differences  in  process  standardization  allow  for  differences  in  the  needs  of 
the  individual  units. 

The  establishment  of  a  clear  operating  model  is  an  organizational  commitment  to  a  new  way 
of  doing  business.  The  selection  of  an  operating  model  is  a  critical  decision  because  it  forms  the 
foundation  for  decision  making,  how  to  strategically  position  the  organization,  and  which 
capabilities  to  develop  and  leverage.  It  guides  the  development  of  business  and  IT  capabilities 
and  drives  the  strategy  and  vision  of  the  company.  According  to  Ross  et  al.  (2006)  companies 
that  have  defined  an  organizational  operating  model  have  reported  31%  higher  operational 
efficiency  over  those  that  don’t 

The  Air  Force  Product  Centers  currently  perform  development  planning  with  specialized 
tools  that  are  specific  to  each  center.  This  leads  to  a  lack  of  commonality  across  the  centers,  not 
only  in  their  tools,  but  standards,  nomenclatures  and  processes.  The  lack  of  commonality  means 
that  the  Air  Force  Product  Centers  are  currently  working  as  diversified  entities  within  AFMC  and 
AFSPC. 

The  diversification  operating  model  is  a  decentralized  organizational  design  that  works  best 
to  support  different  products  and  services  and  benefits  from  local  autonomy  in  deciding  how  to 
address  customer  demands  (Weill,  2005).  The  diversification  operating  model  is  characterized 
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by  having  low  business  process  integration  and  low  business  process  standardization.  While  this 
model  can  work  well  in  a  situation  where  individual  products  are  independent  of  each  other, 

DoD  is  finding  that  more  and  more,  there  is  a  need  for  information  sharability  and  system 
interoperability.  The  Air  Force  Product  Centers  have  independent  transactions  and  operate  as 
unique  entities.  They  have  few  data  standards  across  the  centers  and  most  IT  decisions  are  made 
at  the  center  level.  The  centers  have  control  over  their  process  design,  as  long  as  they  follow  DP 
and  ESE  guidelines.  Entities  using  the  diversified  model  encourage  local  growth  of  the 
individual  entity. 

Based  on  the  current  DoD  acquisition  strategies  to  capitalize  on  information  sharing  and 
weapon  system  interoperability,  there  is  a  need  for  the  business  units  (product  centers)  to  make 
accurate  and  timely  information  available  to  other  business  units  (product  centers)  so  that  system 
interoperability  can  be  designed  into  future  weapon  systems.  Since  the  DoD  acquisition  model  is 
a  common  model  for  all  weapon  system  development,  and  because  of  the  desire  to  promote 
communication  and  understanding  across  the  product  centers,  there  would  be  value  in  having 
them  run  their  business  operations  in  the  same  way.  From  this,  one  can  conclude  that  the 
coordination  operating  model  would  be  preferable.  It  allows  for  information  sharing  across  the 
enterprise,  while  also  supporting  the  individual  differences  of  the  product  centers. 

This  is  particularly  true  since  much  of  the  tenninology  and  language  is  tied  to  specific  phases 
and  operations  within  the  acquisition  lifecycle.  As  an  example  of  how  even  simple  common 
understandings  can  be  difficult  to  achieve,  consider  a  workshop  sponsored  by  CSE  in  summer 
2009.  Representatives  from  the  Air  Force  product  centers,  along  with  AF  XR  organizations 
spent  an  hour  striving  to  come  to  common  agreement  on  the  meaning  of  the  word  “concept”,  as 
used  in  the  term  “concept  development”.  After  an  hour’s  discussion,  the  group  was  able  to 
create  a  common  definition  that  they  would  only  agree  to  for  the  length  of  the  current  workshop. 
If  something  as  fundamental  as  the  definition  of  “concept”  eluded  the  group  for  long  term 
understanding,  one  can  easily  imagine  the  difficulty  that  the  various  actors  in  the  acquisition 
process  will  have 


Coordination  Operating  Model 

Unlike  the  diversification  operating  model,  coordination  calls  for  high  levels  of 
integration  while  allowing  low  levels  of  process  standardization.  Business  units  operating  in  a 
coordination  company  tend  to  share  one  or  more  of  the  following  entities:  customers,  products, 
suppliers,  and  partners.  With  coordination,  key  business  processes  are  often  integrated,  however, 
the  lower  level  business  units  of  the  company  may  have  unique  operational  functions  with 
unique  capabilities.  Ross  et  al.  (2006)  characterizes  coordination  by  the  following  attributes: 


•  Shared  customers,  products,  or  suppliers 

•  Impact  on  other  business  units  transactions 

•  Operationally  unique  business  units  or  functions 

•  Autonomous  business  management 

•  Business  unit  control  over  business  process  design 

•  Shared  customer/supplier/product  data 

•  Consensus  processes  for  designing  IT  infrastructure  services;  IT  application  decisions 
made  in  business  units 


For  companies  with  a  coordination  model,  independent  business  heads  execute  their 
processes  in  the  most  efficient  manner  possible,  but  corporate  directives  and  negotiations  focus 
on  providing  the  best  service  to  the  customer.  Successful  companies  rely  on  incentive  systems 
and  management  training  to  encourage  companywide  thinking  at  the  business  unit  level  (Ross  et 
ah,  2006).  By  integrating,  but  not  standardizing  business  functions,  the  coordination  operating 
model  allows  companies  to  foster  expertise  within  the  business  and  increase  customer  service 
simultaneously.  A  coordination  core  diagram  is  shown  in  Figure  7. 

Coordination  core  diagram 
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Figure  7.  Source:  Derived  from  Ross,  2006 


4.  Stages  of  Enterprise  Architecture  Maturity: 

The  CESE  approach  can  be  strengthened  if  the  centers  have  a  common  architecture  to  begin 
the  development  of  common  standards,  nomenclature,  tools,  processes  and  systems.  “Enterprise 
architecture  (EA)  initiatives  can  involve  dismantling  legacy  systems  or  redesigning  business 
processes”  (Ross,  2005).  Each  of  the  product  centers  currently  have  tools  that  are  specific  to 
their  center,  they  perfonn  different  tasks  and  implement  the  DP  process  in  different  phases.  In 
order  to  improve  collaboration  efforts  among  all  centers,  a  clear  idea  of  their  IT  status  is 
necessary.  Maturity  models  can  be  used  to  support  an  as-is  analysis,  to  derive,  and  prioritize 
improvement  measures  for  the  products  centers. 

“Maturity  models  are  grounded  in  the  concept  of  process  improvement  and  are  derived  from 
stage  theories  which  are  based  on  the  belief  that  systems,  processes,  practices,  activities,  and 
even  enterprises  themselves,  can  and  do  go  through  distinct  stages  over  time”  (Kappelman, 
2010).  According  to  Kappelman  (2010),  maturity  models  include  a  set  of  specifically  described 


stages,  occurring  in  a  given  sequence,  a  list  of  aspects  or  conditions  for  changing  or  evolving 
from  one  stage  to  another  and  a  list  of  aspects  or  conditions  that  must  be  present  in  order  for  the 
transition  to  another  stage  to  have  occurred  and  be  identified  as  having  occurred.  Maturity 
models  can  be  considered  as  evaluative  and  comparative  instruments  to  help  improve 
collaborative  endeavors  across  all  the  centers. 

MIT’s  (Massachusetts  Institute  of  Technology)  Center  for  Information  Systems  Research 
(CISR)  developed  an  architecture  maturity  model  with  four  stages  of  enterprise  architecture. 
These  are  business  silos,  standardized  technology,  optimized  core,  and  business  modularity 
(Table  2).  Both  the  business  units  and  IT  must  pass  through  these  stages  to  move  toward 
enterprise  architecture  maturity  (Ross  et  ah,  2006).  Table  3  shows  the  characteristics  of  each 
stage  from  several  perspectives.  CSE  should  facilitate  the  product  centers  to  move  their 
enterprises  forward  incrementally,  building  buy-in  and  collaboration.  An  assessment  of  the 
product  centers  maturity  level  can  help  CSE  understand  where  the  centers  have  come  from  and 
what  direction  the  centers  should  be  headed. 


Business  Silos 

Standardized 

Technology 

Optimized  Core 

Business 

Modularity 

IT  applications 
serving  local  business 
needs 

Clearly  articulated 
technical  platforms  limiting 
choices  and  increasing 
efficiency 

Standard  data  or 
processes  increasing 
organizational  discipline 

Business  process 
modules  plug  and  play 
enabling  business 
agility 

Table  2:  Architecture  Stages  Definitions  (Derived  from  Ross,  2005) 


The  product  centers  are  currently  operating  in  Stage  1,  business  silos  architecture.  Stage  1  is 
where  “companies  look  to  maximize  individual  business  unit  needs  or  functional  needs”  (Ross  et 
ah,  2006).  At  this  maturity  level,  each  product  center  has  developed  its  own  methods, 
communicates  in  its  own  language  and  appears  only  interested  in  moving  its  center  along.  Over 
time,  CSE  can  measure  the  maturity  of  EA  in  each  center  to  indentify  strengths,  areas  of 
improvement,  and  subsequent  activities  to  effect  improvement  in  the  processes  and  practices 
across  the  centers.  Once  each  product  center  is  assessed,  CSE  can  set  a  course  of  action  to 
advance  the  centers  to  the  next  stage  of  maturity.  Stages  cannot  be  skipped,  because  each  stage 
is  dependent  on  the  capabilities  provided  by  the  previous  stage  for  its  implementation.  The  next 
three  stages  of  the  maturity  model  can  help  move  the  product  centers  toward  reasonable  plans  in 
developing  a  collaborative  effort  with  CSE  advocacy  for  integration  and  standardization. 


Stage  1 
Business 

Silos 

Stage  2 
Standardized 
Technology 

Stage  3 
Optimized 

Core 

Stage  4 
Business 
Modularity 

IT 

Capability 

Local  IT 
applications 

Standard 

technology 

platforms 

Enterprise- wide 
standardized 
processes  or  data 

Plug-and-play 
business  process 
modules 

Business  Objectives 

ROI  of  local 

business 

initiatives 

Reduced  IT  costs 

Cost  and  quality  of 
business  operations 

Speed  to  market; 
strategic  agility 

Funding  Priorities 

Individual 

applications 

Shared 

infrastructure 

services 

Enterprise 

applications 

Reusable 

business 

processes 

Key  Management 
Capability 

Technology- 
enabled  change 
management 

Design  &  update  of 
standards;  funding 
shared  services 

Core  enterprise 
process  definition 
&  measurement 

Core  enterprise 
process  definition 
&  measurement 

Who  Defines 
Applications 

Local  business 
leaders 

IT  and  business 
unit  leaders 

Senior  managers 
and  process  leaders 

IT,  business  and 
industry  leaders 

Key  IT  Governance 
Issues 

Measuring  and 
communicating 
value 

Establishing  local 
vs.  regional  vs. 
global 

responsibilities 

Aligning  project 
priorities  with 
architecture 
objectives 

Defining, 
sourcing  and 
funding  business 
modules 

Strategic 

Implications 

Local/ functional 
Optimization 

[T  efficiency 

Business 

operational 

efficiency 

Strategic  agility 

Table  3:  Stages  of  Enterprise  Architecture  Maturity  (MIT  Sloan  CISR,  2005) 

In  Stage  2,  Standardized  Technology,  CSE  can  facilitate  technology  standards  intended  to 
decrease  the  number  of  platforms  that  are  managed  across  all  the  centers.  This  stage  establishes 
platform  standardization,  such  as  standard  hardware,  operating  systems,  languages  and  database 
management  system  products.  CSE,  along  with  the  product  centers,  can  negotiate  standardize 
technology  to  reduce  the  number  of  products  performing  similar  functions  among  the  centers. 
This  evolution  positions  the  products  center  to  be  able  to  identify  which  processes  should  be 
local  to  their  center  and  which  should  be  standard  across  all  the  centers. 

As  the  product  centers  migrate  through  each  stage,  the  shift  from  local  optimization  to 
enterprise  optimization  begins  to  occur.  In  the  Optimized  Core  stage,  companies  move  from  a 
local  view  of  data  and  applications  to  an  enterprise  view  (Ross  et  al,  2006).  Stage  3  involves 
major  new  enterprise  system  implementations  and  transfonnation  change.  At  this  stage,  the 
product  center  can  begin  to  benefit  from  data  sharing  and  process  standardization  to  facilitate 
achieving  CESE. 

According  to  Ross  (2005),  data  and  process  standardization  when  combined  with  integrating 
technologies  generate  greater  sharing  and  integrated  process  standards.  CSE  can  use  the 
architecture  maturity  stages  to  help  the  product  centers  build  out  their  EA  to  achieve  a  desired 
level  of  integration  and  standardization  across  all  centers.  In  the  final  the  stage,  business 
modularity,  the  architecture  is  able  to  provide  seamless  linkages  between  business  process 
modules.  “With  a  solid  platform  of  core  processes,  data  and  technology,  a  company  can  plug 
and  play  business  modules  on  either  level,  and  modular  interfaces  make  changes  simpler  to 
implement”  (Ross,  2006).  Stage  4  of  the  EA  maturity  model  supports  the  DoD  Net-Centric 
Vision  to  provide  an  information  sharing  environment  among  the  product  centers. 

Net  Centricity 

One  part  of  the  DoD  Net-Centric  Vision  is  to  function  as  one  unified  DoD  Enterprise, 
creating  an  information  advantage  for  our  people  and  mission  partners  by  providing  a  rich 
information  sharing  environment  in  which  data  and  services  are  visible,  accessible, 
understandable,  and  trusted  across  the  enterprise. 


Improving  the  Department’s  ability  to  share  information  helps  realize  the  power  of 
information  as  a  strategic  asset.  Sharing  benefits  include:  achieving  unity  of  effort  across 
mission,  improving  the  speed  and  execution  of  decisions,  achieving  rapid  adaptability  across 
mission  and  coalition  operations,  and  improving  the  ability  to  anticipate  events  and  resource 
needs,  providing  an  initial  situational  advantage  and  setting  the  conditions  for  success 
(Department,  2007).  The  goals  are  to  achieve  an  information  sharing  environment  across 
organizations  to  promote,  encourage,  and  incentivize  sharing  and  achieve  an  extended  enterprise. 

The  DoD  Net-Centric  Data  Strategy  attributes  include  ensuring  data  are  visible,  available, 
and  usable  when  and  where  needed  to  accelerate  decision  making  (Department,  2003).  Newly 
designed  and  real-time  systems  can  offer  services  that  work  in  the  background  collecting  real¬ 
time  data,  storing  it,  and  providing  access  and  discovery  through  an  enterprise  interface  that  is 
available  to  all  centers.  In  the  Scope  of  the  Net-Centric  Data  Strategy,  the  shared  service  is  a 
discoverable  repository  that  houses  the  visible  and  available  data  for  product  centers. 


Case  Study:  Metlife  Adopts  coordination  Operating  Model 


MetLife  is  a  large  enterprise  that  provides  insurance  and  financial  services  to  both 
individuals  and  institutions  and  is  considered  a  gleaming  example  of  a  large  enterprise  that  has 
successfully  implemented  the  coordination  model  (Ross  et  ah,  2006).  Like  our  Air  Force 
acquisition  centers,  MetLife  has  implemented  systems  across  their  operations  that  facilitate  a 
large  set  of  diverse  and  specialized  processes.  Yet,  as  Ross  et  al.  (2006)  explain,  the  “individual 
products  and  product  lines  required  specialized  knowledge,  thereby  limiting  opportunities  for 
standardization  across  products  and  business  units”  (p.  58). 

In  order  to  accommodate  successful  coordination,  MetLife  recognized  the  importance  of 
integrated  data  and  implemented  the  use  of  portals  to  allow  groups  to  share  entry  to  the  hub.  The 
EA  core  diagram  in  Figure  8  illustrates  how  they  managed  to  accomplish  this.  Coordination  is 
achieved  by  linking  the  application  tier  with  the  logic  and  data  tier  through  the  use  of  portals 
accessing  an  integration  hub  -  allowing  a  strategic  information  management  approach  that 
focuses  on  sharing  data. 


MetLJfe’s  core  diagram 


Figure  8.  Source :  Derived  from  Ross  et  al.,  2006 

Case  Study:  Merrill  Lynch  Adopts  coordination  Operating  Model 

Merrill  Lynch  and  its  Global  Private  Client  (GPC)  business  provide  another  example  of  the 
coordination  operating  model.  Merrill  Lynch  offers  a  wide  variety  of  financial  products,  from 


credit  cards  to  loans  to  investing.  GPC  has  over  14,000  financial  advisors  providing  these 
products  at  approximately  630  international  offices.  Merrill  Lynch  also  provides  customers 
multiple  ways  to  remotely  interact  with  their  financial  services,  including  websites  and  call 
centers.  Each  product  line,  regional  office,  and  customer  communication  channel  operates 
differently  from  the  next  due  to  the  nature  of  the  product,  the  needs  of  the  customers  in  a  certain 
region,  or  the  way  a  channel  interacts  with  a  customer.  But  they  all  need  to  work  together  to 
provide  the  customer  a  seamless  experience.  Merrill  Lynch  facilitates  this  through  what  it  calls 
the  Total  Merrill  platform.  This  platform  integrates  access  to  products  across  customer  bases 
and  integrates  access  to  customer  data  across  products  and  channels.  Despite  each  customer, 
product,  and  channel  requiring  and  producing  different  sets  of  data,  they  all  share  data  on  the 
same  network  and  can  quickly  and  easily  pull  data  from  each  other.  Also,  data  that  is  required 
for  multiple  uses  comes  from  a  common  source,  eliminating  redundant  and  conflicting  data. 
Each  product  line  accesses  the  same  real  time  infonnation  to  identify  the  customer  and  the 
current  products  he  or  she  owns.  And  a  customer  can  interact  with  Merrill  Lynch  through  any  of 
the  provided  avenues  and  access  the  same  products  and  information  (Ross  et  al.,  2006). 


5.  Findings  and  Recommendations 

Findings 

Although,  current  DoD  strategy  recognizes  the  value  of  information  sharing  and  system 
interoperability  as  an  essential  capability  of  new  weapon  systems,  the  processes  by  which 
weapon  systems  are  developed  are  stand-alone,  non-information  sharing  efforts. 

The  team  detennined  the  following  findings: 

1 .  The  Air  Force  Product  Centers  appear  to  be  operating  in  Weill’s  diversification  operating 
model.  Characteristics  of  this  model  include  low  business  process  standardization  and  low 
business  process  integration.  There  are  a  number  of  characteristics  that  the  product  centers 
display  that  support  this  conclusion.  Among  those  characteristics  we  found  the  following: 

a.  Each  center  has  a  unique  culture 

f.  Each  center  has  a  specific  mission  with  distinct  functional  requirements 

g.  Each  center  works  with  different  contractors  and  customers 

h.  Each  center  uses  different  business  processes,  standards,  and  technology 

i.  Each  center  is  geographically  separated  from  the  others 

j .  Each  center  has  a  different  organizational  structure 

2.  From  the  standpoint  of  enterprise  architecture  (EA)  the  product  centers  are  in  the  business 
silo  stage.  At  this  stage,  each  center’s  information  stores  and  tools  serves  its  own  local  needs. 
Sharing  across  centers  is  not  a  realistic  option  at  this  stage. 


3.  CSE  initiated  participation  in  the  Development  Planning  working  group;  however,  its 
involvement  is  still  early. 

4.  CSE  has  initiated  working  groups. 

Recommendations 

The  following  recommendations  are  made  in  response  to  the  findings: 

1.  The  product  centers  should  consider  moving  toward  a  Coordination  Operating  Model. 

A  coordination  operating  model  would  better  support  the  DoD  strategy  of  information 
sharing  and  development  of  interoperable  weapon  systems.  Such  a  model  would  provide  the 
coordination  among  the  product  centers  while  still  supporting  the  ability  of  each  center  to 
support  the  needs  of  its  own  types  of  products,  and  its  own  customers. 

2.  The  product  centers  should  consider  the  stage  of  their  enterprise  architecture,  with  a 
goal  of  moving  from  stage  1,  the  Business  Silo  stage  to  stage  three,  Optimized  Core,  or 
stage  four,  Business  Modularity  to  support  the  need  to  develop  interoperable  weapon 
systems. 

Moving  beyond  the  Business  Silos  stage  of  enterprise  architecture  is  a  necessary  requirement 
for  providing  the  necessary  infrastructure  to  support  the  desired  level  of  information  sharing  and 
the  development  of  interoperable  weapon  systems. 

3.  The  Center  for  Systems  Engineering  (CSE)  should  become  the  vehicle  for  coordinating 
the  effort  to  move  the  product  centers  toward  a  coordination  operating  model  and  an 
enhanced  enterprise  architecture  stage. 

CSE  should  become  the  vehicle  for  breaking  down  the  isolation  among  the  centers  and 
for  fostering  integration  across  all  aspects  of  SE  with  a  focus  on  ESE.  CSE  may  consider 
becoming  a  system  of  systems  through  a  strategic  move  toward  a  Coordination  EA  model.  CSE 
has  established  a  system  of  systems  integration  working  group  with  the  following  objectives:  1) 
Address  continued  enterprise  interoperability  and  integration,  2)  Communicate  proposed 
configuration  (technical  baseline)  changes  within  and  across  Centers  and  in  turn  to  all  possibly 
affected  dependent  programs,  3)  Ensure  impacts  to  all  programs  are  reported  at  Configuration 
Steering  Boards  (CSBs),  and  4)  Drive  interoperability  and  integration  focus  into  AF  Program 
Support  (PSR)  process. 

4.  CSE  may  consider  working  with  the  product  centers  to  establish  a  plan  with  scheduled 
milestones  for  moving  toward  compliance  with  the  new  DoD  policy/guidance  regarding 
information  sharing  and  interoperability. 

As  it  currently  stands,  there  appears  to  be  no  leadership  or  governance  guiding  this 
process.  As  a  result,  the  centers  seem  to  lack  motivation  to  make  changes.  The  CSE  can  fill  this 
leadership  gap  and  become  the  catalyst  for  the  move  to  DoD  interoperability  and  infonnation 
sharing.  The  lack  of  interoperability  among  entities  becomes  apparent  when  there  are  high 
profile  operation  failures.  Past  efforts  at  achieving  interoperability  have  resulted  in 


organizations  use  of  translator  functions  to  communicate  on  a  case-by-case  basis.  This 
Information  Exchange  Requirement  (IER)  communication  focuses  only  on  the  information  that 
may  seem  to  be  important  by  the  affected  entities  and  is  based  on  the  organizations’  operating 
protocols.  This  method  of  information  exchange  is  difficult  and  costly.  The  emphasis  of  IER 
does  not  consider  that  information  needs  to  be  widely  shared  to  be  of  most  benefit.  The  legacy 
thinking  that  interoperability  jointness  must  only  be  at  the  operational  level  creates  a  blind  spot 
due  to  the  lack  of  peer-to-peer  communication  at  the  tactical  level.  As  new  capabilities  and  new 
entities  are  deployed,  IER  becomes  an  obstacle  to  interoperability  by  making  it  difficult  to  allow 
the  widespread  sharing  of  information  needed  for  net-work  centric  operations  (Alberts  &  Hayes, 
2003). 

5.  CSE  may  consider  furthering  their  involvement  in  the  Product  Center  working  groups. 

Continued  or  expanded  use  of  these  forums  show  promise  of  producing  integration  solutions 
that  work  for  all  parties  involved.  Most  importantly,  if  the  centers  can  collaborate  and  make 
their  own  changes,  rather  than  have  changes  forced  upon  them,  the  ownership  they  feel  for  the 
solutions  will  greatly  increase  the  likelihood  of  successful  implementation. 


6.  Conclusions 

Each  Product  Center  has  its  own  way  of  doing  business.  As  a  result,  these  diverse  methods 
have  developed  unique  cultures  within  each  Center.  However,  it  is  not  feasible  to  change  the 
entire  culture  of  each  Center,  certainly  not  in  the  short  tenn;  only  the  mindset  that  one  specific 
methodology  is  the  “right”  way  to  do  business.  After  all,  each  Center  has  been  operating 
independent  of  the  others  for  years  and  has  experienced  success  doing  so.  However,  in  order  to 
stay  on  the  cutting  edge,  and  develop  the  interoperable  weapon  systems  demanded  by  the  DoD, 
the  Centers  must  share  information  much  more  broadly  and  do  it  efficiently.  Acting 
independently  only  creates  interoperability  problems  in  a  finished  product.  This  type  of  problem 
is  clearly  seen  in  the  F-22  and  F-35.  These  two  aircraft,  the  most  modem  aircraft  in  our 
inventory,  were  developed  with  overlap  in  time,  yet  their  information  systems  do  not  talk  to  each 
other.  Only  through  a  retrofit  will  these  airframes  be  able  to  share  information  at  the  level 
required  in  today’s  and  tomorrow’s  operating  environments.  Situations  like  this  simply  cannot 
be  allowed  to  happen  moving  forward.  Solutions  to  this  problem  depend  on  a  growing  ability  for 
the  product  centers  to  share  infonnation  and  cooperate  in  the  development  of  future  weapons 
systems.  Approaches  presented  in  this  paper  point  the  way  to  possible  approaches  that  will  move 
our  acquisition  processes  toward  a  more  collaborative  environment,  where  we  can  develop  and 
field  the  weapon  systems  that  our  nation  will  require  in  the  years  to  come. 


Glossary  of  Terms 


AAC 

AETC 

AETC/CC 

AFIT 

AFIT/CC 

AFMC 

AFMC/CC 

AFMC/CV 

AoA 

HQ  AFMC/EN 

AFSPC 

AFSPC/A4A6 

HQ  AFSPC/A5X 

HQ  AFMC/A5C 

AFSPC/CC 

AFSPC/CV 

ASC 

CBA 

CCTD 

CER 

CISR 

CSE 

CESE 

DAPA 

DP 

DPWG 

DoD 

EA 

ESC 

ESE 

GPC 

HQ 


IER 

IS 

IT 

JCIDS 

KM 


Air  Armament  Center 

Air  Education  and  Training  Command 

Air  Education  and  Training  Command  Commander 

Air  Force  Institute  of  Technology 

Air  Force  Institute  of  Technology  Commander 

Air  Force  Materiel  Command 

Air  Force  Materiel  Command  Commander 

Air  Force  Materiel  Command  Vice  Commander 

Analysis  of  Alternatives 

Directorate  of  Engineering 

Air  Force  Space  Command 

Director  of  Logistics  and  Communications 

Policy  and  Integration  Division 

Capability  and  Requirements  Planning  Division 

Air  Force  Space  Command  Commander 

Air  Force  Space  Command  Vice  Commander 

Aeronautical  Systems  Center 

Capabilities  -Based  Assessment 

Concept  Characterization  and  Technical 

Description 

Concept  Exploration  and  Refinement 
Center  for  Information  Systems  Research 
Center  for  Systems  Engineering 
Collaborative  Early  Systems  Engineering 
Defense  Acquisition  Performance  Assessment 
Development  Planning 
Development  Planning  Working 
Group 

Department  of  Defense 
Enterprise  Architecture 
Electronic  Systems  Center 
Early  Systems  Engineering 
Global  Private  Client 
Head  Quarters 
Information 
Exchange 
Requirement 
Information  Systems 
Information  Technology 

Joint  Capabilities  Integration  and  Development  System 
Knowledge  Management 


MIT 

Massachusetts  Institute  of  Technology 

MOA 

Memorandum  of  Agreement 

NCW 

Network-Centric  Warfare 

NWC 

Nuclear  Weapons  Center 

PSC 

Preferred  System  Concept 

Assistance  Secretary  of  the  Air  Force  Director 

SAF/AQX 

Integration 

Assistance  Secretary  of  the  Air  Force  Director 

SAF/AQR 

and  Engineering 

SE 

Systems  Engineering 

SIM 

Strategic  Information  Management 

SMC 

Space  and  Missile  Systems  Center 

TD 

Technology  Development 

USA 

United  States  Army 

USAF 

United  States  Air  Force 

WSARA 

Weapon  Systems  Reform  Act 

XR 

Capabilities  Integration  Directorate 

for  Acquisition 

for  Science,  Technology, 
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